Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding Python 3 support #10

Merged
merged 212 commits into from
May 21, 2019
Merged

Adding Python 3 support #10

merged 212 commits into from
May 21, 2019

Conversation

asmeurer
Copy link
Collaborator

@asmeurer asmeurer commented Apr 5, 2019

Fixes #2

This is the same as #9, but reopened so that Travis works and it hides the commits that are already in master.

TODOs:

  • Fix all test and doctest failures in Python 3
  • Fix all warnings from Python 3
  • Make sure all import files are updated for Python 3 and this is tested
  • Make sure all files have the proper __future__ imports.
  • Update py command line examples
  • Check for any other additional ast node types in Python 3
  • Check for bugs on some Python 3 codebases

Most of the changes were unnecessary, such as converting iterators into lists,
or adding a dependency on futurize.
Most of the unchosen changes were the unnecessary addition of futurize as a
dependency.
It's needed for Python 2/3 compatibility, but isn't included with six.
The exceptions are __init__.py, because __all__ is set to [], and in _py.py,
launch_ipython_with_autoimporter is undefined, but I do not know what it
should actually be (no such function is defined anywhere in pyflyby).
With the exception of those in test_autoimp.py, which are undefined names
intentionally. If it was desired to make pyflakes pass 100% on all test files
those functions could be created using exec().
This breaks pyflakes testing because there are variables that appear to be
unused. When Python 2 support is dropped, these strings can become f-strings.
The code can only run in Python 2, so revert the incorrect change from
futurize.

This fixes 'py console' in Python 2.
This reverts some futurize changes. The tests are only relevant in Python 2,
because they deal with oldstyle classes.
This reverts an incorrect futurize change, and makes it so it should work
properly in both Python 2 and 3.
@asmeurer
Copy link
Collaborator Author

asmeurer commented Apr 5, 2019

I guess Travis doesn't run on draft pull requests? That would make the feature rather useless.

@asmeurer asmeurer marked this pull request as ready for review April 5, 2019 20:58
@asmeurer
Copy link
Collaborator Author

asmeurer commented Apr 5, 2019

The b64decode examples in the auto_eval doctest aren't very good, because it returns bytes in Python 3, producing different output (b'hello' vs. hello). Should I add .decode('utf-8') to the examples, or pick a better function that acts the same in both 2 and 3?

@quarl
Copy link
Member

quarl commented Apr 5, 2019 via email

@asmeurer
Copy link
Collaborator Author

I've gone through all the places in https://greentreesnakes.readthedocs.io/en/latest/nodes.html where Python 2/3 differences are noted and added tests for those node types. I still need to find some good codebases that use Python 3 features to run some smoke tests on. Although I already know of at least one error in the parser, also present in master from the pyflyby sources themself #12.

The file is only used in Python 2 and doesn't have prints. The extra line
changes the docxref test.
It may be why tests are randomly failing on Travis again.
@asmeurer
Copy link
Collaborator Author

I guess this is ready for review. I'll try to think of some good Python 3 codebases I can test it against this weekend. Let me know if you have any suggestions. I'm not aware of any outstanding issues, except for the mandatory imports question, and the upstream fixes.

@asmeurer
Copy link
Collaborator Author

I guess I forgot to mention here that there is another relevant upstream issue, ipython/ipython#11714. In the newest IPython, the input transformers are called multiple times. This results in the pyflyby messages being printed multiple times. The workaround for this isn't exactly pretty. I don't know how to fix the issue upstream, so we'll have to wait on the IPython guys to do something about it.

@@ -24,6 +25,8 @@
from pyflyby._modules import ModuleHandle
from pyflyby._parse import PythonBlock, infer_compile_mode

if PY2:
long = int
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems less than ideal. Why not just change the lone long call to int?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm sure I meant to do this differently, but since it apparently works as an int rather than a long, I'll just remove it.

@@ -4,6 +4,7 @@

from __future__ import absolute_import, division, with_statement

from __future__ import print_function
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be combined with the above import. I don't recall if it works to have multiple time machine statements because it is handled in a special way.

stack[3].function == 'run_cell_async',
# stack[3].function == 'should_run_async',
# stack[1].function == 'check_complete'
]):
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isn't this equivalent to just if stack[3].function == 'run_cell_async':

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, I wanted to leave the other ones in there as comments, in case this isn't actually correct (as far as I can tell from the tests, it should be). I don't fully understand where the three different places are called. I originally thought the inverse of this was correct, but apparently it isn't.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is a little confusing to keep this as it is now. Can you please add a comment saying why the others are commented out and when to uncomment them. Also, you probably don't need the False in there.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I added the False so that I could comment all three out (which is stupid because any([]) is the same as any([False])).

@scopatz
Copy link
Collaborator

scopatz commented May 20, 2019

Thanks @asmeurer - just a couple of small requests

It apparently doesn't matter if it is an int or a long.
setup.py collect_imports is currently broken because of
deshaw#12, but I have added it to .pyflyby
manually. I have not yet re-run tidy-imports on the codebase.
The tidy-imports added a line to the top of the file.
@scopatz
Copy link
Collaborator

scopatz commented May 21, 2019

@quarl - I think this is good to go now. Should I merge it in?

@quarl
Copy link
Member

quarl commented May 21, 2019

Great! Yes please.

@scopatz scopatz merged commit e35ab41 into deshaw:master May 21, 2019
@scopatz
Copy link
Collaborator

scopatz commented May 21, 2019

🎉

@asmeurer asmeurer added this to the FY 2019 - March 2020 milestone Jul 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support for python3 in pyflyby
3 participants